home *** CD-ROM | disk | FTP | other *** search
/ InfoMagic Standards 1994 January / InfoMagic Standards - January 1994.iso / inet / scc / 9314 < prev    next >
Text File  |  1993-07-14  |  15KB  |  300 lines
  1. ===========================================================================
  2. **************************************************************************
  3. Security Bulletin 9314                  DISA Defense Communications System
  4. July 14, 1993            Published by: DDN Security Coordination Center
  5.                                       (SCC@NIC.DDN.MIL)   1-(800) 365-3642
  6.  
  7.                         DEFENSE  DATA  NETWORK
  8.                           SECURITY  BULLETIN
  9.  
  10.   The DDN SECURITY BULLETIN is distributed by the DDN SCC (Security
  11.   Coordination Center) under DISA contract as a means of communicating
  12.   information on network and host security exposures, fixes, and concerns
  13.   to security and management personnel at DDN facilities.  Back issues may
  14.   be obtained via FTP (or Kermit) from NIC.DDN.MIL [192.112.36.5]
  15.   using login="anonymous" and password="guest".  The bulletin pathname is
  16.   scc/ddn-security-yynn (where "yy" is the year the bulletin is issued
  17.   and "nn" is a bulletin number, e.g. scc/ddn-security-9302).
  18.  
  19. + - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - +
  20. !                                                                       !
  21. !     The following important  advisory was  issued by the Computer     !
  22. !     Emergency Response Team (CERT)  and is being relayed unedited     !
  23. !     via the Defense Information Systems Agency's Security             !
  24. !     Coordination Center  distribution  system  as a  means  of        !
  25. !     providing  DDN subscribers with useful security information.      !
  26. !                                                                       !
  27. + - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - +
  28.  
  29. **************************************************************************
  30. CA-93:10                        CERT Advisory
  31.                      July 14, 1993
  32.                             Anonymous FTP Activity
  33.  
  34. ---------------------------------------------------------------------------
  35.  
  36. The CERT Coordination Center has been receiving a continuous stream of 
  37. reports from sites that are experiencing unwanted activities within their 
  38. anonymous FTP areas.  We recognize that this is not a new problem, and we 
  39. have been striving to handle requests for assistance on a one-to-one basis 
  40. with the reporting administrator. However, since this activity does not seem 
  41. to be diminishing, CERT believes that a broad distribution of information 
  42. concerning this problem and corresponding solution suggestions should help 
  43. to address the widespread nature of this activity.
  44.  
  45. We are seeing three types of activity regarding anonymous FTP areas.
  46.  
  47.    A. Improper configurations leading to system compromise.
  48.  
  49.    B. Excessive transfer of data causing deliberate over-filling of
  50.       disk space thus leading to denial of service.
  51.  
  52.    C. Use of writable areas to transfer copyrighted software and other
  53.       sensitive information.
  54.  
  55. This advisory provides an updated version of the anonymous FTP configuration
  56. guidelines that is available from CERT.  The purpose of these guidelines is
  57. to assist system administrators at sites that offer anonymous FTP services.
  58. These guidelines are intended to aid a system administrator in configuring
  59. anonymous FTP capabilities so as to minimize unintended use of services or
  60. resources.  Systems administrators should be aware that anonymous FTP
  61. capabilities should be configured and managed according to the policies
  62. established for their site.
  63.  
  64. You may obtain future copies of these guidelines through anonymous FTP from
  65. cert.org in /pub/tech_tips/anonymous_ftp.
  66.  
  67. ---------------------------------------------------------------------------
  68.  
  69.  
  70.         ANONYMOUS FTP CONFIGURATION GUIDELINES
  71.  
  72. Anonymous FTP can be a valuable service if correctly configured and
  73. administered. The first section of this document provides general guidance in
  74. initial configuration of an anonymous FTP area.  The second section addresses
  75. the issues and challenges involved when a site wants to provide writable
  76. directories within their anonymous FTP areas. The third section provides
  77. information about previous CERT advisories related to FTP services.
  78.  
  79. The following guidelines are a set of suggested recommendations that have been
  80. beneficial to many sites. CERT recognizes that there will be sites that have
  81. unique requirements and needs, and that these sites may choose to implement
  82. different configurations.
  83.  
  84. I.  Configuring anonymous FTP
  85.  
  86.     A. FTP daemon
  87.  
  88.        Sites should ensure that they are using the most recent version
  89.        of their FTP daemon.
  90.  
  91.     B. Setting up the anonymous FTP directories
  92.  
  93.        The anonymous FTP root directory (~ftp) and its subdirectories 
  94.        should not be owned by the ftp account or be in the same group as
  95.        the ftp account.  This is a common configuration problem.  If any of 
  96.        these directories are owned by ftp or are in the same group as the 
  97.        ftp account and are not write protected, an intruder will be able to 
  98.        add files (such as a .rhosts file) or modify other files.  Many sites
  99.        find it acceptable to use the root account.  Making the ftp root 
  100.        directory and its subdirectories owned by root, part of the system 
  101.        group, and protected so that only root has write permission will help 
  102.        to keep your anonymous FTP service secure.
  103.  
  104.        Here is an example of an anonymous FTP directory setup:
  105.  
  106.            drwxr-xr-x  7   root    system  512 Mar 1       15:17 ./
  107.            drwxr-xr-x 25   root    system  512 Jan 4       11:30 ../
  108.            drwxr-xr-x  2   root    system  512 Dec 20      15:43 bin/
  109.            drwxr-xr-x  2   root    system  512 Mar 12      16:23 etc/
  110.            drwxr-xr-x 10   root    system  512 Jun 5       10:54 pub/
  111.  
  112.        Files and libraries, especially those used by the FTP daemon and
  113.        those in ~ftp/bin and ~ftp/etc, should have the same protections
  114.        as these directories.  They should not be owned by ftp or be in the 
  115.        same group as the ftp account; and they should be write protected.
  116.  
  117.     C. Using proper password and group files
  118.  
  119.        We strongly advise that sites not use the system's /etc/passwd file as 
  120.        the password file or the system's /etc/group as the group file in the 
  121.        ~ftp/etc directory.  Placing these system files in the ~ftp/etc 
  122.        directory will permit intruders to get a copy of these files. 
  123.        These files are optional and are not used for access control.
  124.  
  125.        We recommend that you use a dummy version of both the ~ftp/etc/passwd 
  126.        and ~ftp/etc/group files. These files should be owned by root. The
  127.        dir command uses these dummy versions to show owner and group
  128.        names of the files and directories instead of displaying arbitrary 
  129.        numbers.
  130.  
  131.        Sites should make sure that the ~/ftp/etc/passwd file contains no 
  132.        account names that are the same as those in the system's /etc/passwd 
  133.        file.  These files should include only those entries that are relevant 
  134.        to the FTP hierarchy or needed to show owner and group names. In 
  135.        addition, ensure that the password field has been cleared.  The 
  136.        examples below show the use of asterisks (*) to clear the password 
  137.        field.
  138.  
  139.        Below is an example of a passwd file from the anonymous FTP area on
  140.        cert.org:
  141.  
  142.            ssphwg:*:3144:20:Site Specific Policy Handbook Working Group::
  143.            cops:*:3271:20:COPS Distribution::
  144.            cert:*:9920:20:CERT::
  145.            tools:*:9921:20:CERT Tools::
  146.            ftp:*:9922:90:Anonymous FTP::
  147.            nist:*:9923:90:NIST Files::
  148.  
  149.        Here is an example group file from the anonymous FTP area on cert.org:
  150.  
  151.            cert:*:20:
  152.            ftp:*:90:
  153.  
  154.  
  155. II. Providing writable directories in your anonymous FTP configuration
  156.  
  157.     There is a risk to operating an anonymous FTP service that permits 
  158.     users to store files.  CERT strongly recommends that sites do not 
  159.     automatically create a "drop off" directory unless thought has been 
  160.     given to the possible risks of having such a service.  CERT has received 
  161.     many reports where these directories have been used as "drop off" 
  162.     directories to distribute bootlegged versions of copyrighted software or 
  163.     to trade information on compromised accounts and password files.  CERT 
  164.     has also received numerous reports of files systems being maliciously 
  165.     filled causing denial of service problems.  
  166.  
  167.     This section discusses three ways to address these problems. The first is 
  168.     to use a modified FTP daemon. The second method is to provide restricted 
  169.     write capability through the use of special directories. The third method
  170.     involves the use of a separate directory.
  171.  
  172.     A. Modified FTP daemon
  173.  
  174.        If your site is planning to offer a "drop off" service, CERT suggests 
  175.        using a modified FTP daemon that will control access to the "drop off" 
  176.        directory.  This is the best way to prevent unwanted use of writable
  177.        areas. Some suggested modifications are:
  178.  
  179.        1. Implement a policy where any file dropped off cannot 
  180.           be accessed until the system manager examines the file 
  181.           and moves it to a public directory.
  182.        2. Limit the amount of data transferred in one session.
  183.        3. Limit the overall amount of data transferred based on 
  184.           available disk space.
  185.        4. Increase logging to enable earlier detection of abuses.
  186.  
  187.        For those interested in modifying the FTP daemon, source code is 
  188.        usually available from your vendor. Public domain sources are 
  189.        available from:
  190.  
  191.           wuarchive.wustl.edu   ~ftp/packages/wuarchive-ftpd
  192.           ftp.uu.net            ~ftp/systems/unix/bsd-sources/libexec/ftpd
  193.           gatekeeper.dec.com    ~ftp/pub/DEC/gwtools/ftpd.tar.Z
  194.  
  195.        The CERT Coordination Center has not formally reviewed, evaluated, 
  196.        or endorsed the FTP daemons described.  The decision to use the FTP 
  197.        daemons described is the responsibility of each user or organization, 
  198.        and we encourage each organization to thoroughly evaluate these 
  199.        programs before installation or use. 
  200.  
  201.     B. Using protected directories
  202.  
  203.        If your site is planning to offer a "drop off" service and is unable 
  204.        to modify the FTP daemon, it is possible to control access by using a 
  205.        maze of protected directories.  This method requires prior coordination
  206.        and cannot guarantee protection from unwanted use of the writable FTP 
  207.        area, but has been used effectively by many sites.
  208.  
  209.        Protect the top level directory (~ftp/incoming) giving only execute 
  210.        permission to the anonymous user (chmod 751 ~ftp/incoming).  This will 
  211.        permit the anonymous user to change directory (cd), but will not allow 
  212.        the user to view the contents of the directory.
  213.  
  214.        drwxr-x--x  4   root    system  512 Jun 11      13:29 incoming/
  215.  
  216.        Create subdirectories in the ~ftp/incoming using names known only 
  217.        between your local users and the anonymous users that you want to 
  218.        have "drop off" permission.  The same care used in selecting passwords
  219.        should be taken in selecting these subdirectory names because the 
  220.        object is to choose names that cannot be easily guessed.  Please do not
  221.        use our example directory names of jAjwUth2 and MhaLL-iF.
  222.  
  223.            drwxr-x-wx 10   root    system  512 Jun 11      13:54 jAjwUth2/
  224.            drwxr-x-wx 10   root    system  512 Jun 11      13:54 MhaLL-iF/
  225.  
  226.        This will prevent the casual anonymous FTP user from writing files in 
  227.        your anonymous FTP file system.  It is important to realize that this 
  228.        method does not protect a site against the result of intentional or 
  229.        accidental disclosure of the directory names.  Once a directory name 
  230.        becomes public knowledge, this method provides no protection at all 
  231.        from unwanted use of the area.  Should a name become public, a site 
  232.        may choose to either remove or rename the writable directory.
  233.  
  234.     C. Using a single disk drive
  235.  
  236.        If your site is planning to offer a "drop off" service and is
  237.        unable to modify the FTP daemon, it may be desirable to limit
  238.        the amount of data transferred to a single file system mounted
  239.        as ~ftp/incoming.
  240.  
  241.        If possible, dedicate a disk drive and mount it as ~ftp/incoming.
  242.        If this dedicated disk becomes full, it will not cause a denial
  243.        of service problem.
  244.  
  245.        The system administrator should monitor this directory (~ftp/incoming)
  246.        on a continuing basis to ensure that it is not being misused.
  247.  
  248.  
  249. III. Related CERT Advisories
  250.  
  251.     The following CERT Advisories directly relate to FTP daemons or impact
  252.     on providing FTP service:
  253.  
  254.         CA-93:06.wuarchive.ftpd.vulnerability
  255.         CA-92:09.AIX.anonymous.ftp.vulnerability
  256.         CA-88:01.ftpd.hole
  257.  
  258.     Past advisories are available for anonymous FTP from cert.org.
  259.  
  260.  
  261. Copyright (c) Carnegie Mellon University 1993
  262.  
  263.  
  264.  
  265. ---------------------------------------------------------------------------
  266.  
  267.  
  268. If you believe that your system has been compromised, contact the CERT
  269. Coordination Center or your representative in FIRST (Forum of Incident
  270. Response and Security Teams).
  271.  
  272. Internet E-mail: cert@cert.org
  273. Telephone: 412-268-7090 (24-hour hotline)
  274.            CERT personnel answer 8:30 a.m.-5:00 p.m. EST(GMT-5)/EDT(GMT-4),
  275.            and are on call for emergencies during other hours.
  276.  
  277. CERT Coordination Center
  278. Software Engineering Institute
  279. Carnegie Mellon University
  280. Pittsburgh, PA 15213-3890
  281.  
  282. Past advisories, information about FIRST representatives, and other information
  283. related to computer security are available for anonymous FTP from cert.org
  284. (192.88.209.5).
  285.  
  286.  
  287. ****************************************************************************
  288. *                                                                          *
  289. *    The point of contact for MILNET security-related incidents is the     *
  290. *    Security Coordination Center (SCC).                                   *
  291. *                                                                          *
  292. *               E-mail address: SCC@NIC.DDN.MIL                            *
  293. *                                                                          *
  294. *               Telephone: 1-(800)-365-3642                                *
  295. *                                                                          *
  296. *    NIC Help Desk personnel are available from 7:00 a.m.-7:00 p.m. EST,   *
  297. *    Monday through Friday except on federal holidays.                     *
  298. *                                                                          *
  299. ****************************************************************************
  300.